Every day new websites launch offering services which tie together functionality from other sites. A photo lab printing your online photos, a social network using your address book to look for friends, and APIs to build your own desktop application version of a popular site. These are all useful services—what is not so useful about some of the implementations is their request for your username and password to the other site. When you agree to share your secret credentials, you not only expose your password to someone else (yes, that same password you may also use for online banking), you also give them full access to do as they wish. They can do anything they wanted—even change your password and lock you out.
Open authorization, or OAuth, is an open standard for authorization. OAuth allows users to share private resources (e.g., photos, videos, contact lists, access to web sites) stored on one site with a second site without having to hand out login credentials, typically supplying username and password tokens instead. Each token grants access to a specific site (e.g., a video editing site, a microblogging service, or a social network, to name a new) for specific resources (e.g., just videos from a specific album) and for a defined duration (e.g., the next 2 hours). This allows a user to grant a third party access to the user's information stored with another service provider, without sharing the user's access permissions or the full extent of the user's data or access features.
OAuth has been analogized to a valet key provided with a luxury car. The valet key is a special key one may give a parking attendant and, unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is clear: you give someone limited access to your car with a special key, while using your regular key to unlock everything.
The lockout problem is one problem that open authentication services attempt to solve. They allow a user to grant access to his or her private resources on one site (which is called the Service Provider), to another site (called the Consumer or Relying Party, not to be confused with the User). While OpenID is provides a single identity to sign into many sites, OAuth is provides access to your stuff without sharing your identity at all (or its secret parts).
In current identity ecosystems, a relying party (RP), e.g., the web site storing resources being accessed by the second site, sets a policy that allows a requester (e.g., a user, another RP, the third party web site accessing the secured resources) access to a resource controlled by the RP based on a set of authenticated user attributes (e.g., username, address, age, and the like). The resource to be accessed may be, for instance, protected data, a particular computing device, an account, a transaction, or a computing function. For a user to access the RP-protected resource, an identity service provider (IDsP, sometimes also referred to as an IdP or IDP) that is acceptable to the RP will try to match the set of attributes in the form of a credential that can be signed, and the IDsP will present the credential to the user. The user, in turn, can provide the credential to the RP. An example of such an ecosystem is discussed in the paper published in April 2011 by the White House entitled, “National Strategy for Trusted Identities in Cyberspace.”
In current identity ecosystems, the universe of possible identity attributes may be very large, and no single IDsP stores all of the needed attributes (e.g., address, phone number, birthdate, and the like) that RPs may demand at any given time. In addition, a given IDsP might not be the authoritative source for asserting a particular attribute about a user. For example, while a financial institution such as a bank may be a reliable source to assert a first attribute (e.g., an address) of a particular user, the financial institution may not be the most reliable source to assert a second attribute (e.g., a list of allergies to medications) of the user. Furthermore, current identity management systems typically fail to differentiate on the trust value as to how an attribute was originally obtained by the IDsP versus the authentication methodology in which that attribute is provided to an RP. For example, an attribute about a user's address asserted by a financial institution may likely be trusted more by an RP as compared with an assertion by an identity provider that performs no identity proofing when originally acquiring the user's address. In addition, a relying party can only rely on a single IDsP at a time, and that IDsP may not be able to authenticate or provide all necessary attributes.